chore: release v3.0.0 - #52

rusty_alloc

3.0.0 - 2026-10-31

Fixed

• (segment) commit a guarded segment before lifting its guard
• (segment) commit slices as the bump cursor carves them

Fixed

• A thread no longer costs 32 MiB of commit. Every segment committed its
  whole 32 MiB when it was claimed, and each thread's first allocation claims
  one, so on Windows the commit charge grew by 32 MiB per live thread however
  little it allocated (measured, threads that allocate 100 bytes and wait:
  33 / 65 / 162 / 547 MiB for 0 / 1 / 4 / 16 threads, with a 4 MiB working
  set). Segments now commit their slices as they carve them, doubling from
  the header to steps of at most 4 MiB, and return their chunk to the arena
  marked uncommitted unless they ended fully committed; the same threads now
  charge 2 / 2 / 3 / 5 MiB, and 64 threads 14 MiB. Linux under
  overcommit_memory = 2 charges Committed_AS the same way. A refused
  commit is a failed span, as a refused re-commit already was. Off on targets
  whose commit is a no-op (fixed region, wasm) and in the small profile.
• A guarded object freed with purging on no longer leaks its chunk on
  Windows. Since 2.2.4 a freed huge block is purged before its chunks
  return to the arena, and for a guarded object that decommits the guard
  page too; the restore then lifted the guard before re-committing, and
  VirtualProtect refuses decommitted pages. Every such free retired its
  chunk for the life of the process and counted a refused commit in
  stats::commit_failures. The restore now commits first. Only with guarded
  sampling enabled (guarded_max or guarded_set_sample_rate), which is off
  by default.

rusty_alloc-api

2.3.1 - 2026-10-31

Fixed

• Picks up rusty_alloc 2.3.1: the default arena is reserved uncommitted
  and committed a 32 MiB chunk at a time, so a process no longer charges
  1 GiB of commit on Windows or fails the overcommit check on a ~1 GiB Linux
  machine. This crate's code is unchanged.